Warn and fail --check when Go vendor/ or go.mod need a resync (#343, #618) - #1357

LLM Description written by Claude Code:claude-opus-5-5

Fixes #343
Fixes #618

Summary

A Go replace can be wired correctly while the project still won't build, because two files go derives from go.mod no longer match it. Every Go mode now warns about this with the exact command that fixes it, and apply --check / vendor --check treat it as drift. Before, the run exited 0 with no warning and --check said in sync.

Root cause

The Go backends only edit the consumer go.mod replace (go_mod_edit::ensure_replace_entry / drop_replace_entry). Nothing read vendor/modules.txt or the replacement's go.mod requirements, and verify_go_redirect_state only hashed the copy and checked the directive.

Fix

• New vendor::go_consumer_sync::audit(project_root, pristine_go_mods). It is read-only and offline.
  • modules.txt check: finds vendor/modules.txt (the module's own, or the go.work root's), parses its # M v => target lines, and compares them with the socket-owned replace directives in both directions.
  • Requirements check: reads each socket directory copy's go.mod and compares its requires with the consumer's. A requirement the consumer lists at a lower version is always reported. One the consumer doesn't list is reported only when the pristine go.mod shows the patch added or raised it, because upstream go.mods routinely require modules a pruned consumer graph never lists.
• Wired into:
  • apply as run warnings (JSON warnings[] plus stderr), with the module-cache go.mod passed as the pristine
  • apply --check as drift; when only these drifts are present, the "Run socket-patch apply" footer is suppressed because apply can't fix them
  • vendor as warnings and vendor --check as drift (per Go ledger entry)
  • rollback as warnings
  • scan --mode hosted as warnings when it rewrote a go.mod
• docs/ecosystems.md gains "Files go derives from go.mod", a table of both codes and their fixes.

Design decision: socket-patch doesn't run go mod vendor / go mod tidy itself. Both need the go toolchain and the whole module graph (often network), and they rewrite files the user owns. That follows the v5 triage note on both issues: "synchronize … or give an actionable regeneration step". A maintainer could later make auto-running them opt-in.

Known limits:

• Hosted mode gets the modules.txt check but not the requirements check, because the gopatch module's go.mod isn't in the project.
• --check (no module cache) and vendor (no pristine) flag only the "listed lower" shape of Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618, which is the common security-bump case.
• VEX output is unchanged.

Tests (red → green)

• Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343: e2e_golang_build::committed_vendor_dir_needs_go_mod_vendor_after_apply_and_rollback runs against real go. Flow: go mod vendor → apply. It asserts apply emits the warning and that go build really fails with "inconsistent vendoring", then that apply --check exits 1 naming go mod vendor. After go mod vendor, go run prints PATCHED and check exits 0. After rollback, the stale warning appears and check exits 1. On main it fails at "apply must name the vendor/modules.txt regeneration".
• Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618: e2e_golang_build::patched_go_mod_requirement_bump_needs_go_mod_tidy runs against real go. The patch bumps example.com/dep v1.0.0 → v1.1.0 in the upstream go.mod. It asserts the warning, that the default build fails, and that --check exits 1 naming go mod tidy. After go mod tidy, go run prints FIXED-PATCHED and check exits 0. On main it fails at "apply must name the go.mod/go.sum refresh".
• Unit tests in go_consumer_sync::tests:
  • modules.txt missing / recorded / stale
  • user and hosted replaces
  • requirements raised / added / unchanged-unlisted / after tidy

Commands run

• cargo test -p socket-patch-cli --lib --test e2e_golang_build --test e2e_vendor_golang_build --test e2e_golang_hosted_build --test e2e_golang_workspace_build --test e2e_golang_hosted_state --test e2e_golang --test spawn_env_hygiene (go 1.26.3): all green
• cargo test -p socket-patch-core --lib -- go_consumer_sync golang_local go_mod_edit go_sum_edit: 109 passed
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo fmt --check: the changed files are clean

🤖 Generated with Claude Code